The invention relates generally to systems and methods that employ digital signatures and more particularly to systems and methods that initiate generation of a digital signature, such as digital signatures for forms or other non text based information.
Many of today""s communication systems, such as computer networks, telecommunication systems and other systems are increasingly employing digital signature technology to allow units that are communicating within the system to digitally sign data so that a receiver can verify that the data was in fact sent by a sender purporting to be the originator. One well known type of system is a public/private key system that incorporates a digital signature key pair as known in the art. In such systems, a public signature key is known to any participants in the community, and a secret private digital signature key is assigned to each subscriber, such as a software application, a computer terminal, or other entity. Industry standards have developed for electronic mail (e-mail) servers that route e-mails, through a store and forward manner, among members of the communication system community. Such store and forward based communication typically uses for example, a MIME format, as known in the art. In such systems, a user must typically initiate a digital signature process. As such, when text data is sent by an e-mail server or by an originator, the user must manually request and add a digital signature to the information which may then be communicated to another communication unit for verification.
However, increasingly, transactions requiring interactive, generally real time, bi-directional communication, including text and non text information need to be facilitated over worldwide networks and intra-networks, such as systems that employ the use of markup language data. For example, a common markup language used on the Internet is the hypertext markup language (HTML) which is a format used to digitally describe just about everything in the document that is not content. This is sometimes referred to as form data. With conventional markup language servers, such as WEB servers, a browser program or other interfaces do not generally include digital signature engines for interactive communications using for example, markup language based data. Typically when a system does include a digital signature engine of some sort, each interface manufacturer typically has its own format for an inclusion of a transaction based digital signature. However, there is no standardized methodology for utilizing digital signatures with form data. For example a conventional web server typically needs to maintain a set of digital signature request forms for different types of browsers if a single server needs to communicate with multiple different units within a community not containing the same browser. Although systems are known to have form or markup language based digital signature capability, the requirement of maintaining multiple signature request forms for each different type of browser can unnecessarily increase the overhead of a browser or web server. Also, it would be desirable to have a system and method that allowed the facility to incorporate form based digital signature communication with browsers or interfaces that do not have digital signature engines. As different web server formats are developed, and as communication systems grow with users having different types of browsers or browsers with no digital signature capabilities, it would desirable to allow non-repudiation of information to be independent to the type of browser or interface used by a subscriber or software application.
Another problem arises with use of different web browsers having different digital signature programs, since depending upon the type of digital signature algorithm, different web browsers may use different formats for the digital signature key string. A web server receiving this information typically has capabilities for only one or several types of digital signature generators, so that they are limited in the type and number of browsers that they can communicate with. Hence when a web server interfaces with different browsers, a web server needs to send different HTML forms to each browser to let the digital signature generator of the browser know what digital signature format is being used in the transaction. Hence when formats of digital signatures vary among different interfaces to the communication system, it becomes difficult to facilitate communication with new subscribers or existing subscribers with differing markup language data digital signature engines.
Some browsers are known which include an integrated digital signature generator for form based data that utilizes signature initiation data embedded in a subset of data to be signed. The digital signature generator is integrated in the sense that the signature generator uses the same address space as the browser. In one such system, a persistent digital signature is generated so that verification of a signor may be performed after a transaction has occurred However, such systems typically only sign a portion or subset of the data to be signed. As such, these systems do not generally provide an accurate record of what the user actually agreed upon. Such systems are typically dedicated to a particular type of web server or a particular type of browser. Therefore an increase in cost and processing overhead occurs when a web server must interface with browsers having differing digital signature engines. A digital signature plug in for each different type of browser may typically be required.
Also, as is known in the art, proxies are typically used in communication systems for transferring data, such as markup language data between a web server for example and a plurality of browsers. For example, a web proxy is typically a program on a server that redirects information and may provide such capabilities such as caching of information, and authentication of signatures. The proxies generally serve as an intermediate protocol handle. By way of example, an HTTP proxy looks at every header in a form to determine what packets are directed to which proxy address.
Also, it is conventional to have digital signature engines in each proxy to allow the digital signing of information that is sent during each data unit transfer session for determining whether information was corrupted during the transfer. For example a single transaction may require communication of multiple data units of information. The length of a data unit may be set by way of an industry standard such as in the case of the Internet. However any suitable data unit length may be used. The digital signatures for each data unitare discarded upon completion of a transaction and it can take multiple data units to get one form communicated. The data unit digital signatures are generated by the proxies to ensure that information was not modified during transmission. The digital signatures are stripped off below the application level so there is no digital signature on the form (e.g., HTTP form) when it is used by an application for example. In conventional systems employing digital signatures during data unit communication, the digital signature is applied by a server proxy for example so that a browser proxy may receive the signed data and verify the integrity of the data. These digital signatures are then discarded prior to the data being sent to the application or browser requesting the information. As such, data unit digital signature engines are used to ensure that data unit information can be checked for integrity. However, subsequent authentication of the information for the entire transaction is typically not used. As such, there exists a need for a markup language data based system that facilitates improved non-repudiation by utilizing transaction based digital signature methods for markup language based communications.